home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
InfoMagic Standards 1994 January
/
InfoMagic Standards - January 1994.iso
/
iso
/
8649.asc
< prev
next >
Wrap
Text File
|
1992-12-23
|
72KB
|
1,424 lines
Recommendation X.217
ASSOCIATION CONTROL SERVICE DEFINITION FOR OPEN SYSTEMS INTERCONNECTION FOR
CCITT APPLICATIONS1
(Melbourne, 1988)
The CCITT,
considering
(a) that Recommendation X.200 defines the Reference Model of
Open Systems Interconnection for CCITT Applications;
(b) that Recommendation X.210 defines the Open System
Interconnection (OSI) Layer Service Definition Conventions;
(c) that Recommendation X.215 defines the Session Service
Definition for Open Systems Interconnection for CCITT Applications;
(d) that Recommendation X.216 defines the Presentation
Service Definition of Open Systems Interconnection for CCITT
Applications;
(e) that Recommendation X.220 specifies the use of X.200
series protocols in CCITT Applications;
( f) that Recommendation X.227 specifies the Association
Control Protocol Specification for Open Systems interconnection for
CCITT Applications;
(g) that Recommendation X.410-1984 specifies the protocol for
Remote Operation and Reliable Transfer Server for Message Handling
Systems; and
(h) that there is a need for common Association Control to
support various applications,
unanimously declares
that this Recommendation defines the Association Control
Service of Open Systems Interconnection for CCITT Applications as
given in the Scope and Field of Application.
CONTENTS
0 Introduction
1 Scope and field of application
2 References
3 Definitions
3.1 Reference model definitions
3.2 Naming and addressing definitions
3.3 Service conventions definitions
3.4 Presentation service definitions
3.5 ACSE service definitions
4 Abbreviations
5 Conventions
6 Basic concepts
7 Service overview
8 Relationship with other ASEs and lower layer services
8.1 Other application-service-elements
8.2 Presentation-service
8.3 Session-service
9 Service definition
9.1 A-ASSOCIATE service
9.2 A-RELEASE service
9.3 A-ABORT service
9.4 A-P-ABORT service
10 Sequencing Information
10.1 A-ASSOCIATE
10.2 A-RELEASE
10.3 A-ABORT
10.4 A-P-ABORT
Annex A - Usage of ACSE services to achieve compatibility with CCITT
Recommendation X.410-1984, and the basic facilities of the 1988
Message Handling series of CCITT Recommendations
1 Recommendation X.217 and ISO 8649 [Information processing systems - Open
Systems Interconnection - Service definition for the Association Control
Service Element] were developed in close collaboration and are technically
aligned, except for the differences noted in Appendix I.
Rec. X.217 PAGE1
A.1 Compatibility requirements
A.2 Principles for ensuring compatibility
A.3 Usage of Association Control services to ensure
compatibility with X.410-1984
A.3.1 A-ASSOCIATE
A.3.2 A-RELEASE
A.3.3 A-ABORT
A.3.4 A-P-ABORT
A.3.5 State Table
Appendix I - Differences between Recommendation X.217 and ISO
International Standard 8649.
0 Introduction
0.1 This Recommendation is one of a set of Recommendations
produced to facilitate the interconnection of information processing
systems. It is related to other Recommendations in the set as defined
by the Reference Model for Open Systems Interconnection (X.200). The
reference model subdivides the area of standardization for
interconnection into a series of layers of specification, each of
manageable size.
0.2 The goal of Open Systems Interconnection is to allow, with a
minimum of technical agreement outside the inter-connection
recommendations, the interconnection of information processing
systems:
- from different manufacturers;
- under different managements;
- of different levels of complexity; and
- of different technologies.
0.3 This Recommendation recognizes that application-processes may
wish to communicate with each other for a wide variety of reasons.
However, any communication will require the performance of certain
services independent of the reasons for communication. The
application-service-element defined herein provides such services.
0.4 This Recommendation defines services provided by the
application service element for application-association control: the
Association Control Service Element (ACSE). The ACSE provides basic
facilities for the control of an application-association between two
application-entities which communicate by mea s of a presentation-
connection.
0.5 The use of services defined in this Recommendation is also
governed by the use of the presentation-service (X.216) and the
session-service (X.215).
0.6 It is recognized that, with respect to ACSE Quality of
Services (QOS), described in S 9, work is still in progress to
provide an integrated treatment of QOS across all layers of the OSI
Reference Model, and to ensure that the individual treatments in each
layer service satisfy overall QOS objectives in a consistent manner.
As a consequence, a change may be made to this Recommendation at a
later time which reflects further QOS developments and integration.
1 Scope and field of application
This Recommendati n defines ACSE services for application-
association control in an open systems interconnection environment.
The ACSE services are provided by the use of the ACSE protocol
(X.227) in conjunction with the presentation-service (X.216). The
ACSE services assume as a minimum the use of the presentation-service
Kernel functional unit.
This Recommendation does not specify individual
implementations or products nor does it constrain the implementation
of entities and interfaces within a computer system.
No requirement is made for conformance to this Recommendation.
2 References
Recommendation X.200 Reference Model of Open Systems
Interconnection for CCITT applications. (See
also ISO 7498-1)
Recommendation X.210 OSI layer service definition
PAGE2 Rec. X.217
conventions. (See also ISO TR8509)
Recommendation X.215 Session service definition for Open Systems
Interconnection for CCITT applications. (See
also ISO 8326 and ISO 8326 Addendum 2).
Recommendation X.216 Presentation service definition for Open
Systems Interconnection for CCITT
applications. (See also ISO 8822).
Recommendation X.225 Session protocol specification for Open
Systems Interconnection for CCITT
applications. (See also ISO 8327 and ISO 8327
Addendum 2).
Recommendation X.227 Association Control protocol specification
for Open Systems Interconnection for CCITT
applications. (See also ISO 8650).
Recommendation X.410-1984 CCITT Recommendation X.410: Message
Handling Systems: Remote Operation and
Reliable Transfer Server.
ISO 7498-3 Information processing systems - Open Systems
Interconnection - Basic Reference Model -
Part 3: Naming and Addressing.
3 Definitions
3.1 Reference model definitions
This Recommendation is based on the concepts developed in X.200 and
makes use of the following terms defined in it:
a) Application Layer;
b) application-process;
c) application-entity;
d) application-service-element;
e) application-protocol-data-unit;
f ) application-protocol-control-information;
g) presentation-service;
h) presentation-connection;
i) session-service;
j ) session-protocol;
k) session-connection.
3.2 Naming and addressing definitions
This Recommendation makes use of the following terms defined
in ISO 7498-3;
a) application-process title;
b) application-entity qualifier;
c) application-entity title2;
d) application-process invocation-identifier;
e) application-entity invocation-identifier; and
f ) presentation address.
3.3 Service conventions definitions
This Recommendation makes use of the following terms defined
in X.210:
a) service-provider;
b) service-user;
c) confirmed service;
d) non-confirmed service;
e) provider-initiated service;
f ) primitive;
g) request (primitive);
h) indication (primitive);
i) response (primitive); and
j ) confirm (primitive).
3.4 Presentation service definitions
This Recommendation makes use of the following terms defined
in Recommendation X.216:
2 As defined in ISO 7498-3, an application-entity title is composed of an
application-process title and an application-entity qualifier. The ACSE
provides for the transfer of an application-entity title value by the
transfer of its component values.
Rec. X.217 PAGE1
a) abstract syntax;
b) abstract syntax name;
c) default context;
d) defined context set;
e) functional unit [presentation];
f ) normal mode [presentation];
g) presentation context;
h) presentation data value; and
i) X.410-1984 mode [presentation].
3.5 ACSE service definitions
For the purpose of this Recommendation, the following
definitions apply:
3.5.1 application-association; association
A cooperative relationship between two application-entities,
formed by their exchange of application-protocol-control-information
through their use of presentation-services.
3.5.2 application context
An explicitly identified set of application-service-elements,
related options and any other necessary information for the
interworking of application-entities on an application-association.
Note - This definition is subject to refinement as a result of
ongoing work in the area of the Application Layer structure.
3.5.3 Association Control Service Element
The particular application-service-element defined in this
Recommendation.
3.5.4 ACSE service-user
The part of the application-entity which makes use of ACSE
services.
3.5.5 ACSE service-provider
An abstraction of the totality of those entities which provide
ACSE services to peer ACSE service-users.
3.5.6 requestor
The ACSE service-user which issues the request primitive for a
particular ACSE service. For a confirmed service, it also receives
the confirm primitive.
3.5.7 acceptor
f
for a particular ACSE service. For a confirmed service, it also
issues the response primitive.
3.5.8 association-initiator
The ACSE service-user which initiates a particular
association, i.e. the requestor of the A-ASSOCIATE service which
establishes the association.
3.5.9 association-responder
The ACSE service-user which is not the initiator of a
particular association, i.e. the acceptor of the A-ASSOCIATE service
which establishes the association.
3.5.10 normal mode
The mode of ACSE operation which results in the transfer of
ACSE semantics, using the presentation-service.
3.5.11 X.410-1984 mode
The mode of ACSE operation which allows ACSE service-users to
interwork using the protocol specified in CCITT Recommendation X.410
1984. The use of this mode results in no transfer of ACSE semantics.
3.5.12 disrupt
A service procedure is disrupted by another service procedure
if the second service results in service primitives not being used as
specified for the procedure of the first service.
4 Abbreviations
The following abbreviations are used in this Recommendation.
ACSE Association Control Service Element
AE application-entity
ASE application-service-element
OSI Open Systems Interconnection
PAGE2 Rec. X.217
QOS Quality of Service
5 Conventions
5.1 This Recommendation defines services for the ACSE following
the descriptive conventions defined in Recommendation X.210. In ' 9,
the definition of each ACSE service includes a table which lists the
parameters of its primitives. For a given primitive, the presence of
each parameter is described by one of the following values.
blank not applicable
C conditional
M mandatory
P subject to conditions defined in X.216
U user option
i
is semantically equal to the value to its left in the table.
6 Basic concepts
6.1 The reference model (X.200) represents communication between a
pair of application-processes (APs) in terms of communication between
their application-entities (AEs) using the presentation-service. The
functionality of an AE is factor d into a number of application-
service-elements (ASEs). The interaction between AEs is described in
terms of the use of their ASEs' services.
6.2 This Recommendation introduces the additional modelling
concepts of application-association and application context.
6.3 An application-association is a cooperative relationship
between two AEs. It provides the necessary frame of reference between
the AEs in order that they may interwork effectively. This
relationship s formed by the exchange of application-protocol-
control-information between the application-entities through their
use of presentation-services.
6.4 An application context is an explicitly identified set of
application-service-elements, related options and any other necessary
information for the interworking of application-entities on an
application association.
7 Service overview
7.1 This Recommendation defines the following services for the
control of a single association
a) A-ASSOCIATE;
b) A-RELEASE;
c) A-ABORT; and
d) A-P-ABORT.
7.2 The A-ASSOCIATE service causes the start of use of an
association by those ASE procedures identified by the value of
Application Context Name parameter.
Note - The use of an association by several ASEs is the
subject of ongoing work.
7.3 The A-RELEASE service, if successful, causes the completion of
the use of an association by those ASE procedures identified by the
application context which is in effect without loss of information in
transit. However, the success of the A-RELEASE service optionally may
be negotiated.
7.4 The A-ABORT service causes the abnormal release of the
association with the possible loss of information in transit.
7.5 The A-P-ABORT service indicates the abnormal release of the
association as a result of acti n by the underlying presentation-
service with the possible loss of information in transit.
o
of the following modes:
a) normal mode; or
b) X.410-1984 mode.
7.7 The normal mode of operation allows the ACSE service-user to
take full advantage of the functionality provided by both ACSE and
the presentation-service (X.216). n this mode the ACSE service-
provider transfers its semantics using the normal mode of the
presentation-service.
Rec. X.217 PAGE1
7.8 The X.410-1984 mode of operation allows the ACSE service-user
to interwork with a peer using the protocol specified by the CCITT
Recommendation X.410-1984. In this mode, the ACSE service-provider
does not transfer any semantics of its own and uses the X.410-1984
mode of the presentation-service.
8 Relationship with other ASEs and lower layer services
8.1 Other application-service-elements
8.1.1 The ACSE is intended to be used with other ASEs in order to
support a specific information processing task. Therefore, it is
expected that the ACSE will be included in all application context
specifications.
8.1.2 The collection of the ACSE and other ASE(s) included in an
application context are required to use the facilities of the
presentation-service in a coordinated manner.
8.2 Presentation-service
8.2.1 A one-to-one corresponden e exists between an application-
association and a presentation-connection.
8.2.2 The ACSE services require access to the P-CONNECT, P-RELEASE,
P-U-ABORT and P-P-ABORT services. The ACSE services neither use nor
constrain the use of any other presentation service.
8.2.3 The requestor and acceptor of the A-ASSOCIATE service
determine the mode, the default presentation context, and the initial
defined context set of the underlying presentation-connection using
the following A-ASSOCIATE parameter:
- Mode;
- Presentation Requirements;
- Presentation Context Definition List;
- Presentation Context Definition Result List;
- Default Presentation Context Name; and
- Default Presentation Context Result.
spe
specified in X.227 for the ACSE application-protocol-data-units.
Note - The ACSE service-provider is aware of the presentation
context which contains its abstract syntax by a local mechanism.
8.2.5 If the requestor specifies the value ;X.410-1984+ for the Mode
parameter, the ACSE service-provider does not transfer ACSE semantics
and therefore does not require a presentation context for its
abstract syntax. Any user information which the ACSE service-provider
transfers for its service-user uses the unnamed default presentation
context for the X.410-1984 mode of the presentation-service (X.216).
Note - Table 2/X.217 indicates the A-ASSOCIATE service
parameters which are not used in the X.410-1984 mode. None of the
presentation context related parameters are used.
8.3 Session-service
8.3.1 Using the Session Requirements parameter, the A-ASSOCIATE
service requestor and acceptor determine the functional units for the
underlying session-service (X.215).
8.3.2 The rules and parameter value length restrictions of the
underlying session-service affect ACSE service . The ACSE service-
user must be aware of these constraints.
Note - Some examples of these constraints are:
a) Version 1 of the session-protocol (X.225) imposes user data
length restrictions which affect ACSE primitive parameters.
Some special considerations apply to the A-ABORT services
(see ' 9.3).
b) The choice of session functional units for a particular
association affects the rules for the use of ACSE services.
For example, the selection of session tokens controls the
possibilities of negotiated release and release collisions.
9 Service definition
The ACSE services are listed in Table 1/X.217.
TABLE 1/X.217
ACSE-services
Service Type
A-ASSOCIATE Confirmed
A-RELEASE Confirmed
A-ABORT Non-confirmed
A-P-ABORT Provider-initiated
PAGE2 Rec. X.217
9.1 A-ASSOCIATE Service
The A-ASSOCIATE service is used to cause the beginning of the
use of an association; it is a confirmed service.
9.1.1 A-ASSOCIATE Parameters
Table 2/X.217 lists the A-ASSOCIATE service parameters. In
addition, groups of parameters are defined for reference by other
ASEs as follows:
a) Calling AE Title is the composite of the Calling AP Title
and the Calling AE Qualifier parameters;
b) Called AE Title is the composite of the Called AP Title and
the Called AE Qualifier parameters;
c) Responding AE Title is the composite of the Responding AP
Title and the Responding AE Qualifier parameters;
The two components of the AE title (AP title and AE qualifier)
are defined in ISO 7498-3.
Table 2/X.217 [T2.217], p.
TABLE 2/X.217
A-ASSOCIATE parameters
Parameter name Request Indicat Respons Confirm
ion e ation
Mode U M (=)
Application context name a) M M (=) M M (=)
Calling AP title a) U C (=)
Calling AE qualifier a) U C (=)
Calling AP invocation-identifier a)
Rec. X.217 PAGE1
U C (=)
Calling AE invocation-identifier a) U C (=)
Called AP title a) U C (=)
Called AE qualifier a) U C (=)
Called AP invocation-identifier a) U C (=)
Called AE invocation-identifier a) U C (=)
Responding AP title a) U C (=)
PAGE2 Rec. X.217
Responding AE qualifier a) U C (=)
Responding AP invocation-identifier a) U C (=)
Responding AE invocation-identifier a) U C (=)
User information U C (=) U C (=)
Result M M (=)
Result source M
Diagnostic a) U
Rec. X.217 PAGE1
C (=)
Calling presentation address P P
Called presentation address P P
Responding presentation address P P
Presentation context definition list a) P P
Presentation context definition result list a) P P P
Default presentation context name a) P P
PAGE2 Rec. X.217
Default presentation context result a) P P
Quality of service P P P P
Presentation requirements a) P P P P
Session requirements P P P P
Initial synchronization point serial number P P P P
Initial assignment of tokens P P P P
Session-connection identifier a) P P
Rec. X.217 PAGE1
P P
a) Not used in X.410-1984 mode.
9.1.1.1 Mode
This parameter specifies the mode in which the ACSE services
will operate for this association. It takes one of the following
symbolic values:
- normal; or
- X.410-1984.
If this parameter is not included on the request primitive,
the default value of ╗normal½ is used by the ACSE service provider.
This parameter is always present on the indication primitive.
9.1.1.2 Application Context Name
This parameter identifies the application context proposed by
the requestor. The acceptor returns either the same or a different
name. The returned name specifies the application context to be used
for this association.
Note - The offer of an alternate application context by the
acceptor provides a possible mechanism for limited negotiation.
However, the semantics and rules for this exchange are entirely user
specific. If the requestor cannot operate in the acceptor's
application context, it may issue an A-ABORT request primitive.
9.1.1.3 Calling AP Title
This parameter identifies the AP which contains the requestor
of the A-ASSOCIATE service.
9.1.1.4 Calling AE Qualifier
This parameter identifies the particular AE of the AP which
contains the requestor of the A-ASSOCIATE service.
9.1.1.5 Calling AP Invocation-identifier
This parameter identifies the AP invocation which contains the
requestor of the A-ASSOCIATE service.
9.1.1.6 Calling AE Invocation-identifier
This parameter identifies the AE invocation which contains the
requestor of the A-ASSOCIATE service.
9.1.1.7 Called AP Title
This parameter identifies the AP which contains the intended
acceptor of the A-ASSOCIATE service.
9.1.1.8 Called AE Qualifier
This parameter identifies the particular AE of the AP which
contains the intended acceptor of the A-ASSOCIATE service.
9.1.1.9 Called AP Invocation-identifier
This parameter identifies the AP invocation which contains the
intended acceptor of the A-ASSOCIATE service.
9.1.1.10 Called AE Invocation-identifier
This parameter identifies the AE invocation which contains the
intended acceptor of the A-ASSOCIATE service.
9.1.1.11 Responding AP Title
This parameter identifies the AP which contains the actual
acceptor of the A-ASSOCIATE service.
9.1.1.12 Responding AE Qualifier
This parameter identifies the particular AE of the AP which
contains the actual acceptor of the A-ASSOCIATE service.
9.1.1.13 Responding AP Invocation-identifier
This parameter identifies the AP invocation which contains the
actual acceptor of the A-ASSOCIATE service.
9.1.1.14 Responding AE Invocation-identifier
This parameter identifies the AE invocation which contains the
actual acceptor of the A-ASSOCIATE service.
9.1.1.15 User Information
Either the requestor or the acceptor may optionally include
user information. Its meaning depends on the application context
which accompanies the primitive.
Note - For example, this parameter may be used to carry the
initialization information of other ASEs included in the application
PAGE2 Rec. X.217
context specified by the value of the accompanying Application
Context Name parameter.
9.1.1.16 Result3
This parameter is provided by either the acceptor, by the ACSE
service-provider, or by the presentation service-provider. It
indicates the result of using the A-ASSOCIATE service. It takes one
of the following symbolic values:
- accepted;
- rejected (permanent); or
- rejected (transient).
9.1.1.17 Result Source
The value of the parameter is suppli d by the ACSE service-
provider. It identifies the creating source of the Result parameter
and the Diagnostic parameter, if present. It takes one of the
following symbolic values:
- ACSE service-user;
- ACSE service-provider; or
- presentation service-provider.
If the Result parameter has the value ╗accepted½, the value of
this parameter is ╗ACSE service-user½.
9.1.1.18 Diagnostic
This parameter is only used if the Result parameter has the
value of ╗rejected (permanent)½ or ╗rejected (transient)½.
Optionally, it can be used to provide diagnostic information about
the result of the A-ASSOCIATE service.
If the Result Source parameter h s the value ╗ACSE service-
provider½, it takes one of the following symbolic values:
- no reason given; or
- no common ACSE version.
If the Result Source parameter h s the value ╗ACSE service-
user½, it takes one of the following symbolic values:
- no reason given;
- application context name not supported;
- calling AP title not recognized;
- calling AE qualifier not recognized;
- calling AP invocation-identifier not recognized;
- calling AE invocation-identifier not recognized;
- called AP title not recognized;
- called AE qualifier not recognized;
- called AP invocation-identifier not recognized; or
- called AE invocation-identifier not recognized.
9.1.1.19 Calling Presentation Address
This parameter is as defined in Recommendation X.216.
9.1.1.20 Called Presentation Address
This parameter is as defined in Recommendation X.216.
9.1.1.21 Responding Presentation Address
This parameter is as defined in Recommendation X.216.
9.1.1.22 Presentation Context Definition List
This parameter is as defined in Recommendation X.216.
9.1.1.23 Presentation Context Definition Result List
This parameter is as defined in Recommendation X.216.
9.1.1.24 Default Presentation Context Name
This parameter corresponds to the Default Context Name
parameter defined in Recommendation X.216.
9.1.1.25 Default Presentation Context Result
This parameter corresponds to the Default Context Result
parameter defined in Recommendation X.216.
9.1.1.26 Quality of Service
This parameter is as defined in Recommendation X.216.
3 It is recognized that, with respect to this parameter, work is still in
progress to provide an integrated treatment across all layers of the OSI
Reference Model. As a consequence, a change may be made to this
Recommendation at a later time which reflects further developments and
integration.
Rec. X.217 PAGE1
9.1.1.27 Presentation Requirements
This parameter is as defined in Recommendation X.216.
9.1.1.28 Session Requirements
This parameter is as defined in Recommendation X.216.
9.1.1.29 Initial Synchronization Point Serial Number
This parameter is as defined in Recommendation X.216.
9.1.1.30 Initial Assignment of Tokens
This parameter is as defined in Recommendation X.216.
9.1.1.31 Session Connection Identifier
This parameter is as defined in Recommendation X.216.
9.1.2 A-ASSOCIATE service procedure
9.1.2.1 The A-ASSOCIATE service procedure has a one-to-one
correspondence with the P-CONNECT service defined in Recommendation
X.216. When the A-ASSOCIATE service is used, the association is
created simultaneously with the creation of the underlying
presentation-connection.
9.1.2.2 An ACSE service-user which desires to establish an
association issues an A-ASSOCIATE request primitive. The called AE is
identified by parameters of the request primitive. The requestor
cannot issue any primitives except an A-ABORT request primitive until
it receives an A-ASSOCIATE confirm primitive.
9.1.2.3 The ACSE service-provider issues an A-ASSOCIATE indication
primitive to the acceptor.
9.1.2.4 The acceptor accepts or rejects the association by sending
an A-ASSOCIATE response primitive with an appropriate Result
parameter. ACSE service-provider issues an A-ASSOCIATE confirm
primitive having the same Result parameter. The Result Source
parameter is assigned the symbolic value of ╗ACSE service-user½.
9.1.2.5 If the acceptor accepts the association, the association is
available for use. Requestors in both AEs may now use any service
provided by the ASEs included in the application context which in
effect (with the exception of A-ASSOCIATE).
9.1.2.6 If the acceptor rejects the association, the association is
not established.
9.1.2.7 The ACSE service-provider may not be capable of supporting
the requested associatio . In this situation, it returns an A-
ASSOCIATE confirm primitive to the requestor with an appropriate
RESULT parameter. The Result Source parameter is appropriately
assigned either the symbolic value of ╗ACSE service-provider½ or
╗presentation service-provider½. The indication primitive is not
issued. The association is not established.
9.1.2.8 A requestor in either AE may disrupt the A-ASSOCIATE
service procedure by issuing an A-ABORT request primitive. The
acceptor receives an A-ABORT indication primitive. The association is
not established.
9.2 A-Release service
The A-RELEASE service is used by a requestor in either AE to
cause the completion of the use of an association; it is a confirmed
service. If the session Negotiated Release functional unit was
selected for the association, the acceptor may respond negatively
(see S 8.3.2). This causes t e unsuccessful completion of the A-
RELEASE service and the continuation of the association without loss
of information in transit.
9.2.1 A-RELEASE parameters
Table 3/X.217 lists the A-RELEASE parameters.
TABLE 3/X.217
A-RELEASE parameters
Parameter name Request Indication Response Confirmatio
n
Reason a) U C (=) U C (=)
User information a) U C (=) U C (=)
Result M M (=)
a) Not used in X.410-1984 mode.
PAGE2 Rec. X.217
9.2.1.1 Reason
When used on the request primitive, this parameter identifies
the general level of urgency of the request. It takes one of the
following symbolic values:
- normal;
- urgent; or
- user defined.
Note - For example, if the session Negotiated Release
functional unit was selected for the association, the value ╗urgent½
may be used on the request primitive when the requestor desires to
urgently release the association.
When used on the response primitive, this parameter identifies
information about why the acceptor accepted or rejected the release
request. It takes one of the following symbolic values:
- normal;
- not finished; or
- user defined.
Note - For example, if the session Negotiated Release
functional unit was not selected for the association, the value ╗not
finished½ may be used on the response primitive when the acceptor is
forced to release the association but wishes to give a warning that
it has additional information to send or receive.
9.2.1.2 User information
Either the requestor or acceptor may optionally include user
information on the request or response primitive. Its meaning depends
on the application context which is in effect.
9.2.1.3 Result
This parameter is used by the acceptor to indicate if the
request to release the association normally is acceptable. It takes
one of the following symbolic values:
- affirmative; or
- negative.
9.2.2 A-RELEASE service procedure
9.2.2.1 The A-RELEASE service procedure has a one-to-one
correspondence with the P-RELEASE service defined in Recommendation
X.216. When the A-RELEASE service is used, the association is
released simultaneously with the release of the underlying
presentation-connection.
9.2.2.2 An ACSE service-user which desires to release the
association issues an A-RELEASE request primitive. This requestor
cannot issue any further primitives other than an A-ABORT request
primitive until it receives an A-RELEASE confirm primitive.
9.2.2.3 In order to issue an A-RELEASE request primitive, the
requestor is required to meet all the requirements for issui g a P-
RELEASE request (see S 8.2).
9.2.2.4 The ACSE service-provider issues an A-RELEASE indication
primitive to the acceptor. The acceptor then cannot issue any ACSE
primitives other than an A-RELEASE response primitive or an A-ABORT
request primitive.
9.2.2.5 The acceptor replies to the A-RELEASE indication primitive
by issuing an A-RELEASE response primitive with a Result parameter
which has a value of ╗affirmative½ or ╗negative½. The acceptor may
give a negative response only if the session Negotiated Release
functional unit was selected for the association (see S 8.3).
9.2.2.6 If the acceptor gives a negative reponse, it may once again
use any service provided by the ASEs included in the application
context which in effect (with the exception of the A-ASSOCIATE
service). If it gave a positive response, it cannot issue any further
primitives for the association.
9.2.2.7 The ACSE service-provider issues an A-RELEASE confirm
primitive with an ╗affirmative½ or ╗negative½ value for the Result
parameter. If the value is ╗negative½, the requestor may once again
use any of the services provided by the ASEs of the application
context which is in effect (with the exception of A-ASSOCIATE).
Rec. X.217 PAGE1
9.2.2.8 If the value of the Result parameter is ╗affirmative½, the
association and the underlying presentation-connection have been
released.
9.2.2.9 A requestor in either AE may disrupt the A-RELEASE service
procedure by issuing an A-ABORT request. The acceptor receives n A-
ABORT indication. The association is released with the possible loss
of information in transit.
9.2.2.10 An A-RELEASE service procedure collision results when
requestors in both AEs simultaneously issue an A-RELEASE service
primitive. This can occur only when no session tokens are available
on the association (see S 8.3). In this situation, both ACSE service
users receive an unexpected A-RELEASE indication primitive. The
following sequence then occurs to complete the normal release of the
association.
a) The association-initiator issues an A-RELEASE response
primitive.
b) The association-responder waits for an A-RELEASE confirm
primitive from its peer. When it receives one, it then
issues an A-RELEASE response primitive.
c) The association-initiator receives an A-RELEASE confirm
primitive.
9.2.2.11 The association is released when both ACSE service-users
have received an A-RELEASE confirm primitive.
9.3 A-ABORT service
The A-ABORT service is used by a requestor in either AE to
cause the abnormal release of the association. It is a non-confirmed
service. However, because of the possibility of an A-ABORT service
procedure collision (see S 10.3.5), the delivery of the indication
primitive is not guaranteed. However, both AEs are aware that the
association has been released.
9.3.1 A-ABORT parameters
Table 4/X.217 lists the A-ABORT parameters.
TABLE 4/X.217
A-ABORT parameters
Parameter name Request Indication
Abort source a) M
User information U C (=)
a) Not used in X.410-1984 mode.
9.3.1.1 Abort Source
This parameter, whose value is supplied y the ACSE service-
provider, indicates the initiating source of this abort. It takes one
of the following symbolic values:
- ACSE service-user; or
- ACSE service-provider.
9.3.1.2 User Information
The requestor may optionally include user information on the
request primitive. Its meaning depends on the application context
which is in effect.
Note - When ACSE is supported with version 1 of the session-
protocol (X.225), this parameter is subject to length restrictions
mentioned in S 8.3. For use with version 1, the A-ABORT service
procedure does not transfer any of its own semantics, thus allowing
the maximum possible length for presentation data value(s) of the
User Information parameter. In this situation, the Abort Source
parameter of the A-ABORT indication primitive always indicates ╗ACSE
service-user½.
9.3.2 A-ABORT service procedure
9.3.2.1 The A-ABORT service procedure has a one-to-one
correspondence with the P-U-ABORT service defined in Recommendation
X.216. When the A-ABORT service is used, the association is
abnormally released simultaneously with the abnormal release of the
underlying presentation-connection.
9.3.2.2 An ACSE service-user which desires to abnormally release
PAGE2 Rec. X.217
the association issues the A-ABORT request primitive. This requestor
cannot issue any further primitives for the association.
9.3.2.3 The ACSE service-provider issues an A-ABORT indication
primitive to the acceptor. The ACSE service-provider assigns the
value of ╗ACSE service-user½ for the Abort Source parameter. The
association and the underlying presentation-connection have been
released.
9.3.2.4 The ACSE service-provider may itself cause the abnormal
release of the association because of internal errors detected by it.
In this case, the ACSE service-provider issues A-ABORT indication
primitives to acceptors in both AEs. The ACSE service-provider
assigns the value of ╗ACSE service-provider½ to the Abort Source
parameter. The User Information parameter is not used.
9.4 A-P-ABORT service
The A-P-ABORT service is used by the ACSE service-provider to
signal the abnormal release of the association due to problems in
services below the Application Layer. This occurrence indicates the
possible loss of information in transi . A-P-ABORT is a provider-
initiated service.
9.4.1 A-P-ABORT parameter
Table 5/X.217 lists the A-P-ABORT parameter.
TABLE 5/X.217
A-P-ABORT parameter
Parameter name Indication
Provider reason P
Provider Reason: This parameter is as defined in
Recommendation X.216.
9.4.2 A-P-ABORT service procedure
When the ACSE service-provider detects an error reported by
the underlying presentation-service, it issues A-P-ABORT indication
primitives to acceptors in both AEs. The association is abnormally
released. Requestors in both AEs cannot issue any further primitives
for the association.
10 Sequencing information
This clause defines the interaction among the ACSE service
procedures for a particular association.
10.1 A-ASSOCIATE
10.1.1 Type of service
A-ASSOCIATE is a confirmed service.
10.1.2 Usage restrictions
The A-ASSOCIATE service is not used on an established
association.
10.1.3 Disrupted service procedures
The A-ASSOCIATE service procedure does not disrupt any other
service procedure.
10.1.4 Disrupting service procedures
The A-ASSOCIATE service procedure is disrupted by the A-ABORT
service procedures.
10.1.5 Collisions
An A-ASSOCIATE service procedure collision results when
requestors in both AEs simultaneously issue an A-ASSOCIATE request
primitive for each othe . Both ACSE service-users are issued A-
ASSOCIATION indication primitives which represent distinct
associations. Both can choose to accept or reject the indicated
association by issuing an A-ASSOCIATE response primitive with the
appropriate value for its Result parameter. This will result in the
establishment of none, one or two associations.
Note - If an AE has several concurrent associations, a local
mechanism is needed to distinguish between them.
10.2 A-RELEASE
10.2.1 Type of service
A-RELEASE is a confirmed service.
10.2.2 Usage restrictions
Rec. X.217 PAGE1
The A-RELEASE service is only used on an established
association.
10.2.3 Disrupted service procedures
The A-RELEASE service procedure does not disrupt any other
service procedure, except that an A-ABORT indication is suppressed
following issuance of an A-RELEASE response, and that an A-P-ABORT
indication is suppressed following issuance of an A-RELEASE response
or confirm.
10.2.4 Disrupting service procedures
The A-RELEASE service procedure is disrupted by the A-ABORT or
A-P-ABORT service procedures.
10.2.5 Collisions
An A-RELEASE service procedure collision results when
requestors in both AEs simultaneously issue an A-RELEASE request
primitive. The processing of A-RELEASE service procedure collisions
is described in S 9.2.2. 10.2.6 Further sequencing information The
use of the A-RELEASE service is subject to the constraints on t e S-
RELEASE service defined in Recommendation X.215 (see S 8.3).
10.3 A-ABORT
10.3.1 Type of service
A-ABORT is a non-confirmed service.
10.3.2 Usage restrictions
The A-ABORT service has effect only when used on an
association in the process of establishment, on an established
association, or on an association in the process of being released.
10.3.3 Disrupted service procedures
The A-ABORT servi e procedure disrupts the A-ASSOCIATE, A-
RELEASE and A-P-ABORT service procedures.
10.3.4 Disrupting service procedures
The A-ABORT service procedure is disrupted by the A-P-ABORT
service procedure and by the issuance of an A-RELEASE response.
10.3.5 Collisions
An A-ABORT service procedure collision results when requestors
in both AEs simultaneously issue the A-ABORT request primitive. The
collision processing is governed by the P-U-ABORT service defined in
Recommendation X.216. In this situation, neither A-ABORT indication
primitive is issued.
10.3.6 Further sequencing information
Any use of the A-ABORT service results in the abnormal release
of the association, or the abnormal termination of the A-ASSOCIATE
service procedure or the A-RELEASE service procedure with possible
loss of information.
10.4 A-P-ABORT
10.4.1 Type of service
A-P-ABORT is a provider-initiated service.
10.4.2 Usage restrictions
No restrictions are placed on the occurrence of this service.
10.4.3 Disrupted service procedures
The A-P-ABORT service procedure disrupts all other service
procedures.
10.4.4 Disrupting service procedures
The A-P-ABORT service procedure is disrupted by the A-ABORT
service procedure and by the issuance of an A-RELEASE response or
confirm.
ANNEX A
(to Recommendation X.217)
Usage of ACSE services to achieve compatibility with CCITT
Recommendation X.410-1984, and the basic facilities of the 1988
Message Handling series of CCITT Recommendations
A.1 Compatibility requirements
Recommendation X.410, which was adopted by CCITT in 1984, has
been used in a number of Recommendation X.400 Message Handling
products available or under development.
It is essential that the systems following Recommendation
PAGE2 Rec. X.217
X.410-1984 be able to interwork with OSI systems. This principle has
been guiding the development of the OSI ACSE and Presentation service
and protocol, which has been conducted in very close cooperation
between CCITT and ISO.
This Annex shows how the ACSE service is to be used to achieve
compatibility with Recommendation X.410-1984, and to support the
basic facilities of the 1988 Message Handling series of CCITT
Recommendations.
Reference is also made to a companion Annex attached to the
OSI Presentation service (Recommendation X.216) which shows how OSI
Presentation service is to be used in order to achieve compatibility
with Recommendation X.410-1984.
A.2 Principles for ensuring compatibility
The ACSE X.410-1984 mode of operation can be activated
resulting in full encoding alignment with X.410-1984 at the session
user data level. Its effect is to suppress the generation of explicit
ACSE APDUs while maintaining an active ACPM state machine (see
Recommendation X.227, Annex B).
The layered structure of both protocols, which conforms with
the OSI Reference Model, makes it possible to distinguish the
Presentation Layer functions and parameters from those of the
Application Layer. Based on this layering, the following principles
are used to ensure the required compatibility:
a) The functions and the corresponding protocol elements of
X.410-1984 which belong to the Presentation Layer are
integrated into the OSI Presentation protocol, which
remains consistent and satisfies the requirements of the
whole set of OSI applications.
b) The additional functions and protoc l elements of X.410-
1984 are placed in the Application Layer. They are
generated by the Reliable Transfer Service Element (RTSE,
see Recommendations X.218 and X.228 also Recommendation
X.410-1984). They are passed transparently by the ACSE
service-provider during association establishment and
release by making direct use of the Presentation services.
A.3 Usage of Association Control services to ensure compatibility
with Recommendation X.410-1984
The following Association Control services are used:
A-ASSOCIATE
A-RELEASE
A-ABORT
A-P-ABORT
The use of these services is explained in SS A.3.1-A.3.5.
Note - RTORQ, RTOAC, RTORJ and RTAB are names given to APDUs
generated by the RTSE protocol machine.
A.3.1 A-ASSOCIATE
An association is established and the X.410-1984 mode of ACSE
operation is activated with the following combination of A-ASSOCIATE
service parameters:
a) Mode parameter must be set to ╗X.410-1984½ on request
primitive;
b) Presentation Requirements parameter must specify the
kernel.
c) Session Requirements parameter must be set according to
X.410-1984; and
d) User Information:
1) On the request and indication primitives, this parameter
must contain an RTORQ APDU.
2) On the response and confirmation primitives, it must
contain a RTOAC APDU if the association has been
accepted, or a RTORJ APDU if the association has been
rejected.
3) If the ACSE service-provider has rejected the request,
then this parameter is not used.
Rec. X.217 PAGE1
All other A-ASSOCIATE parameters must be absent or as defined
by the Presentation Service and its Annex concerning its use for
X.410-1984 compatibility (Recommendation X.216).
Following the occurrence of an A-ABORT or A-P-ABORT service
event, the initiating RTSE may use the A-ASSOCIATE service an
implementation dependent number of times to attempt recovery. This
use of the service has all parameters absent except for Presentation
User Data which must contain the recovery data from the RT-OPEN
service.
A.3.2 A-RELEASE
The association is released by the use of this service with
only the Result parameter present. The rules governing the use f A-
RELEASE are as in the main body of this document and are identical to
those for P-RELEASE.
A.3.3 A-ABORT
Either ACSE service-user may signal to its peer that it has a
problem and attempt to force the release of an association by using A
ABORT service with all parameters absent except for the Presentation
User data parameter, which must contain an RTAB APDU. The association
is released, and the initiating RTSE may use the A-ASSOCIATE service
to attempt to obtain a new association over which it can execute its
recovery procedures.
A.3.4 A-P-ABORT
Either ACSE service-provider may signal that it has a problem
(internally or with the services which underlie it) to its peer and
force the release of an association by using the A-P-ABORT service as
defined in Recommendation X.216. The association is released, and the
initiating RTSE may use the A-ASSOCIATE service to attempt to obtain
a new association over which it can execute its recovery procedures.
A.3.5 State Table
The state table which governs the operation of the ACSE in
X.410-1984 mode is given in Annex B of Recommendation X.227.
APPENDIX I
(to Recommendation X.217)
Differences between Recommendation X.217 and ISO International
Standard 8649
I.1 Recommendation X.217 and ISO 8649 are technically aligned,
with the following minor exceptions:
I.2 In S 10 on Sequencing Information this Recommendation states
that the A-ABORT and A-P-ABORT services are mutually disruptive, when
they collide (see SS 10.3.3 and 10.4.4). ISO 86 9 states that A-P-
ABORT cannot be disrupted (see SS 10.3.3 and 10.4.4).
I.3 In S 10 on Sequencing Information this Recommendation states
that an A-ABORT indication is suppressed following issuance of n A-
RELEASE response, and that an A-P-ABORT indication is suppressed
following issuance of an A-RELEASE response or confirm (see SS
10.2.3, 10.3.4 and 10.4.4). ISO 8649 states that the A-RELEASE
service procedure does not disrupt any other service procedure (see
SS 10.2.3, 10.3.4 and 10.4.4).
I.4 This Recommendation contains an Annex A, which has not been
included in ISO 8649. Annex A shows how the OSI Association Control
service is to be used in order to achieve compatibility with
Recommendation X.410-1984 and to support the basic facilities of the
1988 message handling services of CCITT Recommendations (the X.400
series).
I.5 There is no equivalent of this Appendix I in ISO 8649.
PAGE2 Rec. X.217
